Code-analysis status: configuration now surfaces the violations (converted to draft)

I pushed a config change and converted this PR to draft, because once the analysis actually runs it reveals a far larger problem than expected.

Root cause of the previous "red with no report"

pmdVersion was 6.55.0. PMD 6.x cannot parse Java 21+ source, so pmdMain threw PMDException: Error while processing on essentially every .java file and never produced findings. Because the PMD/SpotBugs tasks failed, aggregateAnalysisViolations (which only generates the Markdown report, it does not gate) never ran, so the job was red with No files were found ... build/reports/violations/.

Two changes in the latest commit:

1. pmdVersion 6.55.0 → 7.25.0 - supports Java 21 through 26 (the Micronaut/Forge modules compile on Java 25).
2. Code-analysis CI runs report-only (-Pgrails.codeanalysis.ignoreFailures=true) so PMD + SpotBugs complete, the aggregate report is generated, and the full violation list is published to the job summary instead of aborting.

The scope problem

With PMD parsing correctly, the Core build alone reports:

• 5,016 PMD violations
• 187 SpotBugs violations

The Forge and Gradle-plugin builds are not measured yet - realistic total is ~8,000-12,000 violations.

Top PMD rules:

Top SpotBugs bug patterns:

The ruleset currently enables the entire bestpractices + errorprone + security categories, which is why the count is so high - a large share are pure style preferences, and many of the rest require behavior-changing edits to framework internals.

Recommendation

Fixing 8,000-12,000 locations across the framework in one PR is neither reviewable nor safely mergeable. Suggested path before this can gate:

1. Curate the PMD ruleset down to a high-signal subset (and review the SpotBugs reportLevel/effort).
2. Bulk-fix the safe mechanical rules (e.g. the 1,758 MissingOverride).
3. Baseline or defer the behavior-risky rules to follow-up PRs.

Note: PR #15687 (grails-jacoco) is stacked on top of this branch and inherits these jobs, so it is affected by the same decision.

Code-style (Checkstyle) status: forge backlog left red on purpose

Separate from the PMD/SpotBugs report above, this stack also turns on Checkstyle gating for the grails-forge modules (the code-style config + grails-forge/gradle/code-style-config.gradle are part of this branch's diff vs 8.0.x). The Core and Gradle-plugin code-style jobs are clean and pass; only Forge Projects fails.

I briefly made the code-style jobs report-only for consistency with the analysis jobs, then reverted it - we are not masking style errors. The Forge Projects code-style job is intentionally left red for now rather than fixed, because it's the same "huge backlog" situation.

The forge Checkstyle backlog: 1,088 errors across 259 files

By module:

By rule:

Note

Unlike the PMD/SpotBugs findings, every one of these is a purely mechanical formatting rule - no behavior change. The top three (ImportOrder + UnusedImports + EmptyLineSeparator = ~89%) are exactly what an IDE "Optimize Imports" + reformat, or a Spotless/importOrder pass, would fix automatically. So this backlog is safe to clear in bulk whenever we choose to - it's just out of scope for this draft right now.

PR #15687 is stacked on this branch and inherits the same code-style jobs / red Forge result.

This will have to wait for Grails 8.1 or 9, there is too much work left.

@jamesfredley For the SpotBugs and PMD, have two skill features one after running report does not break build but updates a predetermined ISSUE with the report. Have another skill called fix SpotBugsOrPmd that picks one and fixes it and creates a PR. If anyone has tokens to spare could create quite a few focused PRS. It would move issues from under the radar to very visible and we can tackle them whenever we have the bandwidth

I don't think we can merge hibernate 7 without this change. This is a critical component of that merge. We only have it configured to run in hibernate 7.

This PR expanded scope: grails-code-analysis convention plugin (PMD + SpotBugs) applied to 96 subprojects, with GrailsCodeAnalysisExtension. We do not need to do this. The original change was to help implement hibernate 7.

I now understand that PMD is for 3 subprojects right now and not the entire project.  That changes scope and I'll update and move back from draft.

It appeared there was a large amount of work across the whole codebase and I now see that being possible in our short timeline.

1. JDK 25 Compatibility Fix:
   • Removed google-java-format from the grails-forge Spotless configuration, resolving runtime compilation crashes ( NoSuchMethodError ) caused by internal compiler API changes in JDK 25.
2. Unified Styling & Layout Conventions:
   • Modified Spotless configurations in grails-forge ( gradle/code-style-config.gradle ) to use custom conventions ( importOrder + removeUnusedImports ) to mirror Checkstyle's layout
   requirements.
   • Restricted Spotless scans strictly to production Java source files to prevent conflict with tasks generating resources (e.g. copyGrailsWrapper ).
3. Enhanced Checkstyle Rules:
   • Configured Checkstyle in the grails-forge project to run layout validation on all production Java source files.
   • Cleared all formatting and import violations across the grails-forge-core , grails-forge-api , and grails-forge-cli modules.
4. Build Cleanup:
   • Removed obsolete formatting task declarations from the build configurations.

Update — Spotless removed from grails-forge (supersedes the Spotless changes described above)

While clearing the remaining Checkstyle violations, the importOrder + removeUnusedImports Spotless config turned out to be unable to fully mirror Checkstyle:

• Spotless's prefix-based importOrder treats grails.* and org.grails.* as separate groups (inserts a blank line between them), while Checkstyle's regex merges them into one group (forbids that blank
  line). No Spotless configuration can express that merged group, so any file importing both (e.g. AddPropertyCommand) was an unsatisfiable conflict — Spotless and Checkstyle could never both pass.
• Because checkstyleMain depended on spotlessCheck, that conflict (and pre-existing violations elsewhere) were gated/hidden rather than surfaced.

Resolution: removed the bespoke Spotless config from grails-forge entirely. Layout is now owned solely by Checkstyle (verification) + the shared project .idea code-style, which can express the merged
grails group and matches Checkstyle exactly. This puts grails-forge on the same Checkstyle + CodeNarc model as the root build.

• JDK 25 fix still holds — there's no Java formatter left to hit the NoSuchMethodError.
• Dropped the checkstyleMain dependsOn spotlessCheck gate; Checkstyle now runs on all production Java unconditionally.
• Cleared all surfaced violations across grails-forge-core, grails-forge-api, and grails-forge-cli (whitespace, import order, annotation-array indentation).

⚠️ Heads-up: a surprising transitive dependency we hit and deliberately left in place

We could not delete the spotless-plugin-gradle line from grails-forge/buildSrc/build.gradle, even though Spotless is no longer applied. It's load-bearing for dependency resolution, not for formatting:

io.micronaut.build.internal:micronaut-gradle-plugins
└─ com.diffplug.spotless:spotless-plugin-gradle:6.8.0 (old, transitive)
└─ com.diffplug.spotless:spotless-lib-extra:2.27.0
└─ org.codehaus.groovy:groovy-xml:3.0.9 ← Groovy 3 (codehaus)

micronaut-gradle-plugins drags in an old Spotless (6.8.0) that pulls Groovy 3 (org.codehaus.groovy), which collides with the buildSrc's Groovy 4 (org.apache.groovy) and fails resolution. The explicit
spotless-plugin-gradle:6.25.0 we keep forces Spotless up to a Groovy-4-compatible version, overriding the transitive 6.8.0. So the dependency stays purely as a version pin — it is never applied as a
plugin.

Follow-up candidate (out of scope here): replace this implicit pin with an explicit dependency constraint, or exclude the old Spotless from micronaut-gradle-plugins, so the intent is obvious rather than
relying on a leftover implementation line.

Commit: 4149f44

I don't think we can merge hibernate 7 without this change. This is a critical component of that merge. We only have it configured to run in hibernate 7.

@jdaugherty Why is it a critical component of merging an implementation of Hibernate 7?

Also, a general observation, there seems to be a lot of commits with functional and formatting changes combined.
It is helpful if we separate these into different commits.

I don't think we can merge hibernate 7 without this change. This is a critical component of that merge. We only have it configured to run in hibernate 7.

@jdaugherty Why is it a critical component of merging an implementation of Hibernate 7?

Also, a general observation, there seems to be a lot of commits with functional and formatting changes combined.

It is helpful if we separate these into different commits.

We used this plugin only in the hibernate 7 dev to ensure security best practices.

✅ All tests passed ✅

🏷️ Commit: 327cdcb
▶️ Tests: 34760 executed
⚪️ Checks: 37/37 completed

Learn more about TestLens at testlens.app.

I don't think we can merge hibernate 7 without this change. This is a critical component of that merge. We only have it configured to run in hibernate 7.

@jdaugherty Why is it a critical component of merging an implementation of Hibernate 7?
Also, a general observation, there seems to be a lot of commits with functional and formatting changes combined.
It is helpful if we separate these into different commits.

We used this plugin only in the hibernate 7 dev to ensure security best practices.

That is interesting. I have not used PMD before. Looking at the security rule set, there only seems to be two rules, and none of them seems to apply to Hibernate 7 code. Are there other rules that helps ensure security best practices?

Is it a good idea to change Forge styling in this PR?

Is it a good idea to change Forge styling in this PR?

It was failing CodeStyle!!!